192.168.2.36
Analyse: Zu Beginn des Pentests suchte ich nach der Ziel-VM in meinem lokalen Netzwerk. Ich verwendete `arp-scan -l`, um das lokale Netzwerksegment zu scannen, filterte die Ausgabe mit `grep "PCS"`, um Hosts mit MAC-Adressen von PCS Systemtechnik zu identifizieren (häufig bei VirtualBox), und extrahierte die IP-Adresse mit `awk '{print $1}'`. Das Ergebnis war die IP-Adresse `192.168.2.36`.
Bewertung: Dieser erste Schritt war erfolgreich und lieferte schnell die IP-Adresse der Ziel-VM basierend auf ihrer bekannten MAC-Adresse. Die identifizierte IP-Adresse `192.168.2.36` war die Grundlage für alle weiteren Erkundungsschritte.
Empfehlung (Pentester): Nutzen Sie `arp-scan` zur schnellen Host-Erkennung im lokalen Netzwerk.
Empfehlung (Admin): Überwachen Sie Netzwerkaktivitäten auf unautorisierte Scans.
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0) 80/tcp open http Apache httpd 2.4.62 ((Debian)) 873/tcp open rsync (protocol version 31)
Analyse: Ich führte einen ersten schnellen Portscan mit Nmap auf die gefundene IP-Adresse `192.168.2.36` durch. Der Befehl verwendete Standardoptionen für einen schnellen Scan (`-sS -p- -T5`), Versionserkennung (`-sV`), Standard-Skripte (`-sC`) und OS-Erkennung (`-AO`). Die Ausgabe wurde mit `grep open` gefiltert, um sofort die offenen Ports zu sehen. Die Ergebnisse zeigten, dass die Ports 22 (SSH), 80 (HTTP) und 873 (Rsync) offen sind. Die Dienstversionen OpenSSH 8.4p1, Apache httpd 2.4.62 und Rsync (Protokoll Version 31) wurden identifiziert.
Bewertung: Dieser schnelle Scan lieferte einen klaren Überblick über die primäre Angriffsfläche. Die identifizierten offenen Ports und Dienstversionen sind die Grundlage für die weiteren Enumerations- und Angriffsversuche. Der offene Rsync-Port (873) ist besonders interessant, da er oft für Dateiübertragungen und Synchronisierung verwendet wird und potenzielle Informationslecks oder unauthentifizierten Zugriff ermöglichen kann.
Empfehlung (Pentester): Beginnen Sie immer mit einem schnellen Portscan, um die offenen Dienste zu identifizieren. Achten Sie auf ungewöhnliche offene Ports, die auf spezifische Dienste hinweisen.
Empfehlung (Admin): Minimieren Sie die Anzahl der nach außen exponierten Dienste. Deaktivieren Sie unnötige Dienste.
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-06-11 12:38 CEST Nmap scan report for sabu.hmv (192.168.2.36) Host is up (0.00017s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0) | ssh-hostkey: | 3072 f6:a3:b6:78:c4:62:af:44:bb:1a:a0:0c:08:6b:98:f7 (RSA) | 256 bb:e8:a2:31:d4:05:a9:c9:31:ff:62:f6:32:84:21:9d (ECDSA) |_ ssh-hostkey: 256 3b:ae:34:64:4f:a5:75:b9:4a:b9:81:f9:89:76:99:eb (ED25519) 80/tcp open http Apache httpd 2.4.62 ((Debian)) |_http-title: epages |_http-server-header: Apache/2.4.62 (Debian) 873/tcp open rsync (protocol version 31) MAC Address: 08:00:27:AE:72:62 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Aggressive OS guesses: OpenWrt 21.02 (Linux 5.4) (96%), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) (96%), Linux 4.15 - 5.19...) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.17 ms sabu.hmv (192.168.2.36)
Analyse: Ich führte einen vollständigen, detaillierten Nmap-Scan auf `sabu.hmv` (192.168.2.36) durch. Die Ausgabe bestätigte die offenen Ports 22 (SSH), 80 (HTTP) und 873 (Rsync) mit den identifizierten Versionen. Für Port 80 zeigte der HTTP-Titel "epages". Der Rsync-Dienst wurde als Protokollversion 31 identifiziert. Die OS-Erkennung schätzte das System als Linux ein. Die MAC-Adresse bestätigte die virtuelle Umgebung.
Bewertung: Diese detaillierte Nmap-Ausgabe lieferte alle notwendigen Informationen über die offen liegenden Dienste. Die genauen Versionen von OpenSSH und Apache sind relevant für die Suche nach Exploits. Der offene Rsync-Dienst auf Port 873 mit Protokollversion 31 ist der vielversprechendste Angriffspunkt, da Rsync oft unzureichend gesichert ist. Der HTTP-Titel "epages" deutet auf eine spezifische Webanwendung hin.
Empfehlung (Pentester): Untersuchen Sie die gefundenen Dienstversionen auf bekannte Schwachstellen. Priorisieren Sie ungewöhnliche Dienste wie Rsync auf Port 873. Recherchieren Sie gezielt nach Schwachstellen für diese spezifischen Dienste.
Empfehlung (Admin): Deaktivieren Sie alle unnötigen Dienste. Sichern Sie Rsync-Server strikt ab, verwenden Sie Authentifizierung und beschränken Sie den Zugriff nur auf benötigte Clients. Halten Sie alle Dienste auf dem neuesten Stand und patchen Sie bekannte Schwachstellen.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.36 + Target Hostname: sabu.hmv + Target Port: 80 + Start Time: 2025-06-11 12:39:18 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.62 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 8b8, size: 6353cb6850240, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + OPTIONS: Allowed HTTP Methods: HEAD, GET, POST, OPTIONS . + 7962 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2025-06-11 12:39:37 (GMT2) (19 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Ich führte einen Nikto-Scan auf dem Webserver auf Port 80 (`http://sabu.hmv`) durch. Nikto prüfte auf gängige Web-Schwachstellen und Konfigurationsprobleme. Die Ausgabe bestätigte die Apache-Version und die erlaubten HTTP-Methoden (`HEAD`, `GET`, `POST`, `OPTIONS`). Es wies auf fehlende Sicherheits-Header (`X-Frame-Options`, `X-Content-Type-Options`) und ein potenzielles ETag-Problem hin (CVE-2003-1418). Es wurden keine CGI-Verzeichnisse gefunden.
Bewertung: Der Nikto-Scan lieferte keine kritischen direkten Exploits für den Webserver, bestätigte aber allgemeine Konfigurationsprobleme (fehlende Header). Diese Funde sind weniger kritisch, aber Teil des Gesamtbildes der Sicherheitsposition. Der Webserver selbst schien keine offensichtlichen gängigen Web-Schwachstellen zu haben, die Nikto erkennen konnte. Die Konzentration musste auf andere Dienste, insbesondere Rsync, gerichtet werden.
Empfehlung (Pentester): Beachten Sie alle Funde von automatisierten Scannern, auch die scheinbar weniger kritischen. Sie können auf die allgemeine Härtungsposition hindeuten.
Empfehlung (Admin): Konfigurieren Sie Webserver mit empfohlenen Sicherheits-Headern.
* Host sabu.hmv:80 was resolved. * IPv6: (none) * IPv4: 192.168.2.36 * Trying 192.168.2.36:80... * Connected to sabu.hmv (192.168.2.36) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: sabu.hmv > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Wed, 11 Jun 2025 10:40:40 GMT Date: Wed, 11 Jun 2025 10:40:40 GMT < Server: Apache/2.4.62 (Debian) Server: Apache/2.4.62 (Debian) < Last-Modified: Fri, 16 May 2025 08:38:56 GMT Last-Modified: Fri, 16 May 2025 08:38:56 GMT < ETag: "8b8-6353cb6850240" ETag: "8b8-6353cb6850240" < Accept-Ranges: bytes Accept-Ranges: bytes < Content-Length: 2232 Content-Length: 2232 < Vary: Accept-Encoding Vary: Accept-Encoding < Content-Type: text/html Content-Type: text/html < * Connection #0 to host sabu.hmv left intact
Analyse: Ich holte die HTTP-Header für die Hauptseite auf Port 80 mit `curl -Iv http://sabu.hmv` ab. Die Ausgabe bestätigte die Apache-Version und die erlaubten HTTP-Methoden, ähnlich wie Nikto. Die Header enthielten keine sofort ersichtlichen kritischen Informationen, außer den üblichen fehlenden Sicherheits-Headern.
Bewertung: Die HTTP-Header-Analyse bestätigte die Webserver-Details, lieferte aber keine neuen Angriffspunkte. Die Konzentration blieb auf dem Rsync-Dienst.
Empfehlung (Pentester): Holen Sie immer die HTTP-Header ab, um Serverinformationen zu verifizieren.
Empfehlung (Admin): Minimieren Sie die Informationen, die in HTTP-Headern preisgegeben werden.
epages In der chinesischen Internetkultur ist Sabulaji ein Wort mit großer Persönlichkeit und Freude, was die Pinyin-Transliterationsform von "dumm und nicht wenige Leute" ist. "Silly is not a few bites" ist eine unbeschwerte und spielerische Art zu sagen, dass jemand ein bisschen albern, albern, ein wenig abwertend, aber normalerweise weniger ernst und eher lustig und selbstironisch ist. Wenn Sie also sehen, dass sabulaji im Code, ID oder Tag erscheint, bedeutet das wahrscheinlich: Diese Person ist entweder ein bisschen wie eine Zwei oder versteht das Meme wirklich. ___________________________________________________________________________________________________________________ http://sabu.hmv/icons/small/ Forbidden You don't have permission to access this resource. Apache/2.4.62 (Debian) Server at sabu.hmv Port 80 c
Analyse: Ich betrachtete den Inhalt der Hauptseite auf Port 80 (`http://sabu.hmv`). Die Seite trug den Namen "epages" (wie im HTTP-Titel) und enthielt einen Text, der die Bedeutung des Wortes "Sabulaji" in der chinesischen Internetkultur erklärte. Der Text beschrieb "Sabulaji" als Pinyin-Transliteration für "dumm und nicht wenige Leute" und wies darauf hin, dass das Wort im Code, ID oder Tag erscheinen könnte. Ein Versuch, auf das Verzeichnis `/icons/small/` zuzugreifen, führte zu einem "403 Forbidden" Fehler.
Bewertung: Die Webseite selbst lieferte keine direkten Schwachstellen oder Zugangsdaten, aber der Text über "Sabulaji" war ein sehr starker Hinweis. Die Erwähnung, dass das Wort im Code, ID oder Tag erscheinen könnte, zusammen mit der Bedeutung ("dumm und nicht wenige Leute"), legte nahe, dass "sabulaji" ein wichtiger Benutzername, ein Passwort oder ein Teil davon sein könnte. Der 403 Fehler auf `/icons/small/` zeigte, dass nicht alle Verzeichnisse zugänglich waren.
Empfehlung (Pentester): Lesen Sie den Inhalt von Webseiten sorgfältig auf Hinweise oder versteckte Botschaften. Achten Sie auf Eigennamen, ungewöhnliche Wörter oder Sätze, die auf Benutzernamen, Passwörter oder Konzepte hinweisen könnten.
Empfehlung (Admin): Verwenden Sie keine offensichtlichen oder thematisch zusammenhängenden Wörter oder Phrasen als Benutzernamen oder Passwörter. Deaktivieren Sie die Verzeichnislistung und sichern Sie sensible Verzeichnisse.
Analyse: Der Rsync-Dienst auf Port 873 war der offensichtlichste Angriffspunkt. Ich testete die Verbindung mit Netcat (`nc -nv 192.168.2.36 873`). Die Antwort `@RSYNCD: 31.0` bestätigte, dass der Rsync-Daemon läuft und Protokollversion 31 verwendet. Ich nutzte anschließend das Nmap-Skript `rsync-list-modules` (`nmap -p 873 --script rsync-list-modules 192.168.2.36`), um verfügbare Rsync-Module aufzulisten. Die Ausgabe zeigte zwei Module: `public` mit der Beschreibung "Public Files" und `epages` mit der Beschreibung "Secret Documents".
Bewertung: Der Rsync-Dienst war aktiv und hatte zwei Module konfiguriert. Das `public`-Modul klang nach frei zugänglichen Dateien, während das `epages`-Modul ("Secret Documents") sehr vielversprechend für das Auffinden sensibler Daten war. Die Möglichkeit, Rsync-Module aufzulisten, ist oft der erste Schritt zur Interaktion mit dem Dienst.
Empfehlung (Pentester): Wenn Rsync auf Port 873 offen ist, versuchen Sie immer, die verfügbaren Module aufzulisten (z.B. mit `rsync --list-modules` oder Nmap-Skripten).
Empfehlung (Admin): Konfigurieren Sie Rsync so, dass keine Module unauthentifiziert aufgelistet oder auf sie zugegriffen werden kann. Deaktivieren Sie die Modulauflistung.
(UNKNOWN) [192.168.2.36] 873 (rsync) open @RSYNCD: 31.0
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-06-11 13:01 CEST Nmap scan report for sabu.hmv (192.168.2.36) Host is up (0.00016s latency). PORT STATE SERVICE 873/tcp open rsync | rsync-list-modules: | | public Public Files |_ epages Secret Documents MAC Address: 08:00:27:AE:72:62 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds
Ich erstellte ein lokales Verzeichnis auf meinem Kali-System (`public_files`), um die Dateien zu speichern, die ich vom `public` Rsync-Modul herunterladen würde.
Bewertung: Dieser organisatorische Schritt war notwendig, um die heruntergeladenen Dateien sauber zu speichern.
Empfehlung (Pentester): Erstellen Sie lokale Verzeichnisse, um Daten von Zielsystemen systematisch zu speichern.
Empfehlung (Admin): Keine spezifische Empfehlung.
receiving incremental file list ./ todo.list sent 46 bytes received 552 bytes 1.196,00 bytes/sec total size is 433 speedup is 0,72
Ich versuchte, Dateien vom `public` Rsync-Modul herunterzuladen. Ich verwendete den Befehl `rsync -av rsync://192.168.2.36/public/ ./public_files/`. Die Optionen `-a` (Archivmodus, kopiert rekursiv und behält Berechtigungen etc.) und `-v` (verbose) wurden verwendet. Ich versuchte, vom Modul `public` auf der Ziel-VM (`rsync://192.168.2.36/public/`) in mein lokales Verzeichnis `./public_files/` zu kopieren. Die Ausgabe zeigte, dass der Kopiervorgang startete (`receiving incremental file list`) und eine Datei namens `todo.list` heruntergeladen wurde. Der Vorgang wurde erfolgreich abgeschlossen.
Bewertung: Erfolgreich! Ich konnte ohne Authentifizierung auf das `public` Rsync-Modul zugreifen und die Datei `todo.list` herunterladen. Dies ist eine Schwachstelle, da unauthentifizierter Zugriff auf Rsync-Module oft sensible Daten preisgibt.
Empfehlung (Pentester): Prüfen Sie immer, ob Rsync-Module unauthentifizierten Zugriff erlauben. Laden Sie alle Dateien aus öffentlich zugänglichen Modulen herunter.
Empfehlung (Admin): Konfigurieren Sie Rsync-Module so, dass sie Authentifizierung erfordern (`auth users`, `secrets file`) und/oder beschränken Sie den Zugriff per IP-Adresse (`hosts allow`).
To-Do List ========= 1. sabulaji: Remove private sharing settings - Review all shared files and folders. - Disable any private sharing links or permissions. 2. sabulaji: Change to a strong password - Create a new password (minimum 12 characters, include uppercase, lowercase, numbers, and symbols). - Update the password in the system settings. - Ensure the new password is not reused from other accounts. =========
Ich las den Inhalt der heruntergeladenen Datei `todo.list` mit dem Befehl `cat todo.list`. Die Datei enthielt eine To-Do-Liste mit zwei Einträgen, die beide mit "sabulaji:" begannen und sich auf das Entfernen privater Freigabeeinstellungen und das Ändern zu einem starken Passwort bezogen.
Bewertung: Die `todo.list` Datei lieferte einen wichtigen Hinweis: Es gibt einen Benutzer namens `sabulaji`, der wahrscheinlich der Hauptbenutzer oder Administrator ist. Die To-Do-Einträge deuten darauf hin, dass es Probleme mit unsicheren Freigaben und einem schwachen Passwort für diesen Benutzer gab. Dies ist ein klarer Hinweis darauf, dass `sabulaji` ein Ziel für die Privilegieneskalation ist und dass Brute-Force-Angriffe auf seinen Account oder die Suche nach ungesicherten Freigaben aussichtsreich sein könnten. Der Name "sabulaji" stimmt mit dem Hinweis von der Webseite überein.
Empfehlung (Pentester): Analysieren Sie alle gefundenen Textdateien auf Benutzernamen, Passwörter, Hinweise oder To-Do-Listen. Diese können wertvolle Informationen für die weitere Vorgehensweise enthalten. Konzentrieren Sie sich auf den identifizierten Benutzernamen `sabulaji`.
Empfehlung (Admin): Speichern Sie niemals interne To-Do-Listen mit sensiblen Informationen (wie Benutzernamen und Hinweise auf Sicherheitsprobleme) in öffentlich zugänglichen Verzeichnissen.
Ich erstellte ein weiteres lokales Verzeichnis auf meinem Kali-System (`epages_files`), um die Dateien vom `epages` Rsync-Modul zu speichern.
Bewertung: Dies war ein notwendiger organisatorischer Schritt, um die Dateien aus dem zweiten Rsync-Modul separat zu speichern.
Empfehlung (Pentester): Organisieren Sie heruntergeladene Daten systematisch.
Empfehlung (Admin): Keine spezifische Empfehlung.
Password: @ERROR: auth failed on module epages rsync error: error starting client-server protocol (code 5) at main.c(1850) [Receiver=3.4.1]
Ich versuchte, Dateien vom `epages` Rsync-Modul herunterzuladen (`rsync -av rsync://192.168.2.36/epages/ ./epages_files/`). Im Gegensatz zum `public`-Modul forderte das `epages`-Modul ein Passwort an (`Password:`). Da ich keins eingeben konnte (oder ein falsches eingab), schlug der Versuch mit der Fehlermeldung `@ERROR: auth failed on module epages` und `rsync error: error starting client-server protocol (code 5)` fehl.
Bewertung: Das Ergebnis bestätigte, dass das `epages` Rsync-Modul durch Authentifizierung geschützt ist. Dies ist eine korrekte Sicherheitskonfiguration. Um auf dieses Modul zugreifen zu können, musste ich das korrekte Passwort finden. Die Fehlermeldung ist klar und hilfreich für die Fehlersuche.
Empfehlung (Pentester): Wenn Rsync-Module Authentifizierung erfordern, versuchen Sie, Passwörter durch Brute-Force oder durch Ausnutzung anderer Schwachstellen zu finden.
Empfehlung (Admin): Sichern Sie alle Rsync-Module durch Authentifizierung. Verwenden Sie starke Passwörter.
The authenticity of host '192.168.2.36 (192.168.2.36)' can't be established. ED25519 key fingerprint is SHA256:O2iH79i8PgOwV/Kp8ekTYyGMG8iHT+YlWuYC85SbWSQ. This host key is known by the following other names/addresses: ~/.ssh/known_hosts:71: [hashed name] ~/.ssh/known_hosts:90: [hashed name] Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.2.36' (ED25519) to the list of known hosts. root@192.168.2.36's password: Permission denied, please try again. root@192.168.2.36's password: rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(716) [Receiver=3.4.1]
Ich versuchte, Rsync über SSH zu nutzen (`rsync -av 192.168.2.36:module_name_1 /data/tmp`), um zu sehen, ob ich mich per SSH mit Rsync-Funktionalität verbinden konnte. Der Befehl versuchte, eine Verbindung als `root` zum Zielsystem (`192.168.2.36`) herzustellen. Ich musste die Host-Authentizität bestätigen. Dann wurde ich nach dem Passwort für `root` gefragt. Ich gab ein falsches Passwort ein (oder ließ es leer), was zu "Permission denied" führte. Ich brach den Versuch dann ab.
Bewertung: Dieser Versuch, Rsync über SSH zu nutzen, bestätigte, dass SSH auf Port 22 aktiv war (was bereits im Nmap-Scan bekannt war) und dass der Root-Login über Passwort authentifiziert werden muss. Dies war nicht der primäre Weg, da das Rsync-Modul auf Port 873 das Hauptziel war und ein separater Dienst ist. Der Versuch war aber nützlich, um die SSH-Konfiguration zu überprüfen.
Empfehlung (Pentester): Testen Sie verschiedene Wege, um auf Dienste zuzugreifen (direkt, über SSH-Tunnel etc.). Wenn Passwörter benötigt werden, notieren Sie dies und konzentrieren Sie sich auf andere Vektoren zur Erlangung der Passwörter.
Empfehlung (Admin): Deaktivieren Sie den Root-Login über Passwort in der SSH-Konfiguration (`PermitRootLogin no` oder `without-password`). Verwenden Sie Schlüssel-basierte Authentifizierung für Root, wenn überhaupt benötigt.
options Module options (auxiliary/scanner/rsync/modules_list): Name Current Setting Required Description ---- --------------- -------- ----------- RHOSTS yes The target host(s), see [Link: https://docs.metasploit.com/docs/using-metasploit/basics/u | Ziel: https://docs.metasploit.com/docs/using-metasploit/basics/u] sing-metasploit.html RPORT 873 yes The target port (TCP) TEST_AUTHENTICATION true yes Test if the rsync module requires authent ication THREADS 1 yes The number of concurrent threads (max one per host) View the full module info with the info, or info -d command. set rhosts 192.168.2.36 rhosts => 192.168.2.36 set rport 873 rport => 873 run [+] 192.168.2.36:873 - 2 rsync modules found: public, epages [*] 192.168.2.36:873 - Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed
Ich nutzte das Metasploit Framework (`msfconsole`) um das `rsync-list-modules` Nmap-Skript zu ersetzen oder zu verifizieren. Ich startete `msfconsole` im Schnellmodus (`-q`) und führte direkt den Befehl `use auxiliary/scanner/rsync/modules_list` aus. Ich prüfte die Optionen (`options`), setzte den Ziel-Host (`set rhosts 192.168.2.36`) und den Port (`set rport 873`), und führte das Modul aus (`run`). Die Ausgabe bestätigte erneut die Existenz der Module `public` und `epages` auf Port 873.
Bewertung: Das Metasploit-Modul bestätigte die Ergebnisse des Nmap-Skripts und zeigte die verfügbaren Rsync-Module an. Dies war nützlich, um die Funktionalität des Rsync-Dienstes mit einem anderen Tool zu verifizieren. Die Module `public` und `epages` wurden klar identifiziert.
Empfehlung (Pentester): Nutzen Sie verschiedene Tools oder Frameworks (wie Metasploit) zur Verifizierung von Schwachstellen und zur Informationsbeschaffung. Wenn ein Dienst einen bekannten Exploit hat oder es Module/Funktionen zu identifizieren gibt, prüfen Sie, ob entsprechende Module in Frameworks existieren.
Empfehlung (Admin): Überwachen Sie Ihr Netzwerk auf Scans mit Security-Tools wie Metasploit.
Die `todo.list` Datei deutete darauf hin, dass der Benutzer `sabulaji` ein schwaches Passwort hatte und es ändern sollte. Ich beschloss, einen gezielten Wörterbuchangriff auf das `epages` Rsync-Modul zu versuchen, das Authentifizierung erforderte. Ich nutzte das Tool `crunch`, um eine speziell angepasste Wortliste zu generieren. Der Befehl `crunch 12 12 -t sabulaji%^+@ -o sabu.txt` erzeugte eine Wortliste (`sabu.txt`) mit Passwörtern der Länge 12, die auf dem Muster `sabulaji` basierten und spezielle Zeichen enthielten (`%^+@`). Die Annahme war, dass das Passwort des Benutzers `sabulaji` in irgendeiner Form "sabulaji" plus einige Sonderzeichen enthielt, wie in der To-Do-Liste angedeutet wurde.
Bewertung: Das Generieren einer gezielten Wortliste basierend auf den Hinweisen aus der `todo.list` Datei war eine intelligente Strategie für einen effizienteren Brute-Force-Angriff. Anstatt eine riesige allgemeine Wortliste zu verwenden, konzentrierte ich mich auf Passwörter, die wahrscheinlich "sabulaji" enthielten. Dies erhöhte die Wahrscheinlichkeit, das korrekte Passwort zu finden.
Empfehlung (Pentester): Nutzen Sie Hinweise aus der Enumeration (Benutzernamen, Kommentare, Logdateien) zur Erstellung gezielter Wortlisten. Verwenden Sie Tools wie `crunch` oder `cewl` zur Generierung von Wortlisten basierend auf Mustern oder Webseiten-Inhalten.
Empfehlung (Admin): Erzwingen Sie strenge Passwortrichtlinien, die die Verwendung von leicht zu erratenden Passwörtern, die auf Benutzernamen oder Firmennamen basieren, verhindern.
Password: @ERROR: auth failed on module epages rsync error: error starting client-server protocol (code 5) at main.c(1850) [Receiver=3.4.1]
root@192.168.2.36's password: Permission denied, please try again. root@192.168.2.36's password: rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(716) [Receiver=3.4.1]
Ich wiederholte einige frühere, gescheiterte Rsync-Versuche. Der Versuch, auf das `epages` Modul zuzugreifen, forderte erneut ein Passwort an und schlug fehl. Der Versuch, Rsync über SSH als Root zu nutzen, scheiterte ebenfalls aufgrund falscher Passwortauthentifizierung. Diese Wiederholungen zeigten, dass diese Wege ohne das korrekte Passwort weiterhin blockiert waren.
Bewertung: Die Wiederholung dieser Befehle diente der Dokumentation der Sackgassen, bevor der erfolgreiche Weg gefunden wurde. Sie bestätigten, dass die Authentifizierung für das `epages` Modul und für den Root-SSH-Login aktiv war.
Empfehlung (Pentester): Dokumentieren Sie auch die gescheiterten Versuche im Bericht. Sie zeigen, welche Wege nicht funktioniert haben und warum.
Empfehlung (Admin): Überwachen Sie Login-Versuche und Brute-Force-Angriffe auf Dienste wie Rsync und SSH.
Analyse: Basierend auf dem Hinweis aus der `todo.list` Datei und der Tatsache, dass das `epages` Rsync-Modul Authentifizierung erforderte, vermutete ich, dass der Benutzername `sabulaji` und ein Passwort benötigt wurden. Ich führte einen gezielten Wörterbuchangriff auf das `epages` Rsync-Modul durch, um das Passwort zu finden. Ich nutzte eine `while read` Schleife in Bash, um Zeile für Zeile Passwörter aus der `rockyou.txt` Wortliste zu lesen. Für jedes Passwort setzte ich die Umgebungsvariable `RSYNC_PASSWORD` auf das aktuelle Passwort (`export RSYNC_PASSWORD="$p"`) und versuchte dann, das `epages` Modul als Benutzer `sabulaji` anzusprechen (`rsync -q --no-motd rsync://sabulaji@192.168.2.36/epages/ ./rsync_ergebnis/`). Ich verwendete die Optionen `-q` (quiet) und `--no-motd`, um die Ausgabe zu minimieren, und leitete die Standardausgabe und Fehlerausgabe ins Nichts (`>/dev/null`), um nur bei Erfolg eine Ausgabe zu erhalten. Wenn der Befehl erfolgreich war (Rückgabewert 0), gab ich das gefundene Passwort aus und beendete die Schleife. Die Schleife fand das Passwort `admin123`.
Bewertung: Erfolgreich! Der Wörterbuchangriff auf das `epages` Rsync-Modul fand das Passwort `admin123` für den Benutzer `sabulaji`. Dies ist ein kritischer Erfolg und der Initial Access Vektor. Ein schwaches Passwort, das mit einem Brute-Force-Angriff gefunden werden konnte, schützte ein Modul mit "Secret Documents".
Empfehlung (Pentester): Führen Sie immer gezielte Wörterbuchangriffe auf Dienste durch, die Authentifizierung erfordern, insbesondere wenn Sie Benutzernamen (wie `sabulaji` hier) oder Hinweise auf Passwortmuster (wie in der `todo.list`) gefunden haben. Nutzen Sie populäre Wortlisten (wie `rockyou.txt`) oder erstellen Sie angepasste Listen.
Empfehlung (Admin): Erzwingen Sie strenge Passwortrichtlinien, die die Verwendung von schwachen, häufig verwendeten Passwörtern (wie `admin123`) verhindern. Implementieren Sie Mechanismen zur Erkennung und Abwehr von Brute-Force-Angriffen (z.B. Account-Sperrung, Rate Limiting). Überwachen Sie Login-Versuche.
[-] Probiere: sabulaji [+] Passwort gefunden: admin123
Mit dem gefundenen Passwort (`admin123`) versuchte ich erneut, Dateien vom `epages` Rsync-Modul herunterzuladen. Ich verwendete denselben `rsync` Befehl wie zuvor, aber diesmal wurde das Passwort über die `RSYNC_PASSWORD` Umgebungsvariable gesetzt, die ich vor dem Ausführen des erfolgreichen Befehls setzen musste (oder durch Eingabe des Passworts bei Aufforderung). Der Befehl war `rsync -av rsync://sabulaji@192.168.2.36/epages/ ./epages_files/`. Da das Passwort korrekt war, wurde die Authentifizierung erfolgreich durchgeführt, und Rsync begann mit der Übertragung der Dateien. Die Ausgabe zeigte, dass Dateien empfangen wurden (hier nicht explizit im Text, aber impliziert durch den Erfolg).
Bewertung: Erfolgreich! Der Zugriff auf das `epages` Rsync-Modul war nun möglich. Dies ist der entscheidende Schritt des Initial Access. Das Modul mit der Beschreibung "Secret Documents" war nun für mich zugänglich, was die Möglichkeit eröffnete, sensible Dateien herunterzuladen, die für die Privilegieneskalation wichtig sein könnten.
Empfehlung (Pentester): Nutzen Sie gefundene Passwörter sofort, um sich an den entsprechenden Diensten zu authentifizieren und auf geschützte Bereiche zuzugreifen. Laden Sie alle Dateien aus kompromittierten Rsync-Modulen herunter und analysieren Sie sie sorgfältig.
Empfehlung (Admin): Überprüfen Sie die Protokolle von Rsync-Servern auf erfolgreiche Logins nach fehlgeschlagenen Versuchen.
Libreoffice secrets.doc Hier ist die Übersetzung - Ich habe die entscheidenden Informationen für dich hervorgehoben. Die Kunst, Geheimnisse zu wahren In einer Welt, die von Informationen überquillt, ist es sowohl eine Kunst als auch eine Herausforderung, Geheimnisse zu wahren. Ob es sich um ein persönliches Tagebuch handelt, das unter der Matratze versteckt ist, oder um eine kryptische Nachricht, die in einem vollen Café weitergereicht wird – der Reiz des verborgenen Wissens zieht uns alle in seinen Bann. Nehmen wir zum Beispiel den alten Serverraum in meinem Büro. Es ist eine staubige Ecke, in der vergessene Maschinen leise vor sich hin summen. Auf einem von ihnen, einem Relikt aus den frühen 2000er Jahren, läuft noch immer ein FTP-Dienst. Der Admin hat, in einem Moment fragwürdiger Urteilsfähigkeit, den Standard-Account "welcome" genannt. Ich habe mitgehört, wie ein Kollege darüber kicherte und sagte, das Passwort sei etwas absurd Einfaches wie "P@ssw0rd123!" – kaum ein Geheimnis, das es wert wäre, gehütet zu werden, aber es ist seit Jahren unberührt. Bei Geheimnissen geht es jedoch nicht nur um Passwörter oder versteckte Dateien. Es geht um die Absicht. Ein geflüstertes Gerücht über ein Projekt, ein kodierter Blick zwischen Freunden oder sogar die Art, wie wir unsere Gedanken hüten. Die besten Geheimnisse sind jene, die sich direkt vor unseren Augen verbergen, unbemerkt vom abgelenkten Blick. Also, wie meistern wir diese Kunst? Erstens, falle nicht auf. Mache dein Geheimnis nicht offensichtlich. Zweitens, schütze es mit etwas Stärkerem als "P@ssw0rd123!" – vielleicht mit einer Phrase, die nur du verstehen würdest. Und schließlich, vertraue nur sparsam. Selbst die einladendsten Systeme können dich verraten, wenn du nicht vorsichtig bist. Am Ende erinnern uns Geheimnisse daran, dass nicht alles geteilt werden muss. Manche Dinge lässt man besser ungesagt, oder zumindest jenen überlassen, die wissen, wo sie suchen müssen. Deine nächsten Schritte für die CTF: Der Text ist ein direkter Hinweis. Du musst dich per FTP verbinden. Dienst: FTP (File Transfer Protocol) gibt es nicht daher werden wir SSH verwenden... Benutzername: welcome Passwort: P@ssw0rd123! Der Befehl im Terminal würde wahrscheinlich so aussehen: Generated bash ssh welcome@192.168.2.36 Dann wirst du nach dem Namen (welcome) und dem Passwort (P@ssw0rd123!) gefragt.
Nachdem ich die Dateien aus dem `epages` Rsync-Modul heruntergeladen hatte, analysierte ich ihren Inhalt. Eine der Dateien war `secrets.doc` (wahrscheinlich eine umbenannte oder kopierte Datei, die ursprünglich auf der VM lag), die einen Text über "Die Kunst, Geheimnisse zu wahren" enthielt. Innerhalb dieses Textes gab es einen Absatz, der explizit einen alten FTP-Dienst im Büro erwähnte, einen Standard-Account namens "welcome" und das Passwort "P@ssw0rd123!". Am Ende des Textes gab es einen direkten Hinweis für die CTF: "Der Text ist ein direkter Hinweis. Du musst dich per FTP verbinden.", gefolgt von "Dienst: FTP (File Transfer Protocol) gibt es nicht daher werden wir SSH verwenden...", "Benutzername: welcome" und "Passwort: P@ssw0rd123!".
Bewertung: Fantastisch! Diese Datei aus dem "Secret Documents" Modul lieferte direkt die Zugangsdaten für den Benutzer `welcome`: Benutzername `welcome` und Passwort `P@ssw0rd123!`. Obwohl im Text von FTP die Rede war, wurde im selben Text klargestellt, dass SSH verwendet werden soll. Dies ist der direkte Weg zur Erlangung initialen Zugriffs auf das System über SSH mit den Zugangsdaten des Benutzers `welcome`. Der Text diente als klarer Hinweis für die CTF.
Empfehlung (Pentester): Analysieren Sie alle heruntergeladenen Dateien sorgfältig auf Zugangsdaten, Passwörter, Hinweise oder interne Notizen. Textdateien, Dokumente oder Konfigurationsdateien sind oft gute Fundorte. Folgen Sie Hinweisen, die in solchen Dateien gegeben werden.
Empfehlung (Admin): Speichern Sie niemals Zugangsdaten in Klartextdateien auf Systemen. Stellen Sie sicher, dass sensible Dokumente nicht über unsichere Dienste (wie unauthentifiziertes Rsync) zugänglich sind. Verwenden Sie keine leicht zu erratenden Passwörter.
Kurzbeschreibung: Dieser Proof of Concept demonstriert die Erlangung von Initial Access als Benutzer `welcome` durch die Ausnutzung einer unsicheren Rsync-Konfiguration. Ein öffentlich zugängliches Rsync-Modul enthielt eine Datei mit Zugangsdaten für den Benutzer `welcome`, die einen direkten SSH-Login ermöglichten.
Voraussetzungen:
Schritt-für-Schritt-Anleitung & Beweismittel:
1. Identifizierung der Rsync-Module und unauthentifizierter Zugriff auf das `public` Modul:
... | public Public Files |_ epages Secret Documents ...
... todo.list ...
Der Rsync-Dienst auf Port 873 wurde identifiziert und seine Module aufgelistet (`public`, `epages`). Das `public`-Modul erlaubte unauthentifizierten Zugriff und enthielt die Datei `todo.list`, die Hinweise auf den Benutzer `sabulaji` und Passwortprobleme gab.
2. Brute-Force des `epages` Rsync-Moduls und Download der `secrets.doc` Datei:
... [+] Passwort gefunden: admin123 ...
Ein Brute-Force-Angriff auf das `epages` Rsync-Modul mit dem Benutzernamen `sabulaji` und der `rockyou.txt` Wortliste fand das Passwort `admin123`. Mit diesen Zugangsdaten konnte auf das `epages` Modul zugegriffen und die Datei `secrets.doc` heruntergeladen werden.
3. Extraktion der Zugangsdaten für Benutzer `welcome` aus `secrets.doc`:
... Benutzername: welcome Passwort: P@ssw0rd123! ...
Die Datei `secrets.doc` enthielt in Klartext die Zugangsdaten für den Benutzer `welcome`: Benutzername `welcome`, Passwort `P@ssw0rd123!`.
4. SSH-Login als Benutzer `welcome`:
welcome@192.168.2.36's password: Linux Sabulaji 4.19.0-27-amd64 #1 SMP Debian 4.19.316-1 (2024-06-25) x86_64 ... welcome@Sabulaji:~$
Mit den gefundenen Zugangsdaten konnte ich mich erfolgreich per SSH als Benutzer `welcome` anmelden und eine interaktive Shell auf dem Zielsystem erhalten. Fantastisch der zugriff als welcome war erfolgreich nun haben wir unser Ziel erreicht.
Erwartetes Ergebnis: Erlangung von Zugangsdaten für einen Benutzer (hier `welcome`) und erfolgreicher Login über einen verfügbaren Dienst (hier SSH).
Tatsächliches Ergebnis: Zugangsdaten für Benutzer `welcome` wurden aus einer Datei in einem unsicheren Rsync-Modul extrahiert und ein SSH-Login als `welcome` wurde erfolgreich durchgeführt.
Risikobewertung:
Auswirkung: Hoch. Die unsichere Rsync-Konfiguration ermöglichte die Offenlegung sensibler Dokumente, die zu Zugangsdaten für einen regulären Benutzer führten. Ein kompromittiertes Benutzerkonto kann zur weiteren Enumeration und Privilegieneskalation genutzt werden.
Wahrscheinlichkeit: Hoch. Die Schwachstelle (unauthentifiziertes Rsync-Modul mit sensiblen Daten) war direkt ausnutzbar. Das Passwort des geschützten Moduls war schwach und leicht zu knacken.
Gesamtrisiko: Hoch.
Empfehlungen:
Empfehlung (Admin):
Analyse: Nachdem ich Zugriff als Benutzer `welcome` erlangt hatte, begann ich mit der Privilegieneskalation auf dem System. Zuerst prüfte ich, ob der Benutzer `welcome` `sudo`-Berechtigungen hatte, indem ich `sudo -l` ausführte. Die Ausgabe zeigte eine interessante Regel: `(sabulaji) NOPASSWD: /opt/sync.sh`. Dies bedeutete, dass der Benutzer `welcome` das Skript `/opt/sync.sh` als Benutzer `sabulaji` ausführen durfte, ohne ein Passwort eingeben zu müssen (`NOPASSWD`).
Bewertung: Das Auffinden einer `NOPASSWD` Regel für das Skript `/opt/sync.sh`, das als Benutzer `sabulaji` ausgeführt werden kann, ist ein klarer Vektor zur Privilegieneskalation zum Benutzer `sabulaji`. Ich musste nun das Skript `/opt/sync.sh` untersuchen, um zu verstehen, wie es funktioniert und ob es eine Möglichkeit bietet, es zur Ausführung von Code als `sabulaji` zu missbrauchen.
Empfehlung (Pentester): Prüfen Sie immer `sudo -l` für jeden neuen Benutzer. `NOPASSWD`-Einträge für Skripte sind oft ausnutzbar. Untersuchen Sie den Inhalt der Skripte, die Sie mit `sudo` ausführen dürfen, genau.
Empfehlung (Admin): Weisen Sie `NOPASSWD` Berechtigungen für Skripte nur mit äußerster Vorsicht zu. Stellen Sie sicher, dass Skripte, die mit erhöhten Rechten ausgeführt werden, keine Schwachstellen aufweisen (z.B. unsichere Nutzung von Benutzereingaben, PATH-Hijacking, Race Conditions).
Matching Defaults entries for welcome on Sabulaji: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User welcome may run the following commands on Sabulaji: (sabulaji) NOPASSWD: /opt/sync.sh welcome@Sabulaji:~$ ls .. sabulaji welcome
total 24 drwxr-xr-x 2 welcome welcome 4096 May 16 01:21 . drwxr-xr-x 4 root root 4096 May 15 12:39 .. lrwxrwxrwx 1 root root 9 May 15 12:47 .bash_history -> /dev/null -rw-r--r-- 1 welcome welcome 220 Apr 11 22:27 .bash_logout -rw-r--r-- 1 welcome welcome 3526 Apr 11 22:27 .bashrc -rw-r--r-- 1 welcome welcome 807 Apr 11 22:27 .profile -rw-r--r-- 1 root root 44 May 15 12:49 user.txt
flag{user-cf7883184194add6adfa5f20b5061ac7}
Als Benutzer `welcome` konnte ich die Datei `user.txt` in meinem Home-Verzeichnis auslesen. Die Ausgabe war die Zeichenkette `flag{user-cf7883184194add6adfa5f20b5061ac7}\}$.
Bewertung: Das war die User Flag! Das Auffinden und Dokumentieren der User Flag ist ein wichtiger Meilenstein im Pentest.
Empfehlung (Pentester): Suchen Sie die User Flag im Home-Verzeichnis des Benutzers.
Empfehlung (Admin): Speichern Sie sensitive Informationen nicht in Benutzerverzeichnissen.
#!/bin/bash if [ -z $1 ]; then echo "error: note missing" exit fi note=$1 if [[ "$note" == *"sabulaji"* ]]; then echo "error: forbidden" exit fi difference=$(diff /home/sabulaji/personal/notes.txt $note) if [ -z "$difference" ]; then echo "no update" exit fi echo "Difference: $difference" cp $note /home/sabulaji/personal/notes.txt echo "[+] Updated."
Ich las den Inhalt des Skripts `/opt/sync.sh` aus, das ich als Benutzer `sabulaji` über `sudo` ausführen durfte. Das Skript nimmt ein Argument (`$1`), das als `note` gespeichert wird. Es prüft, ob das Argument leer ist. Es prüft, ob das Argument den String "sabulaji" enthält und bricht ab, wenn dies der Fall ist. Dann berechnet es den Unterschied (`diff`) zwischen `/home/sabulaji/personal/notes.txt` und dem übergebenen Argument (`$note`). Wenn es einen Unterschied gibt, wird dieser ausgegeben, die übergebene Datei (`$note`) nach `/home/sabulaji/personal/notes.txt` kopiert und eine Erfolgsmeldung ausgegeben.
Bewertung: Das Skript `/opt/sync.sh` weist eine klare Schwachstelle auf: Es führt den `diff`-Befehl mit einem vom Benutzer kontrollierten Dateipfad (`$note`) aus, ohne den `PATH` des Skripts sicher zu setzen. Der `diff`-Befehl ist anfällig für PATH-Hijacking. Wenn ich ein eigenes, schädliches Skript namens `diff` in einem Verzeichnis erstelle, das vor dem tatsächlichen `diff`-Binary im `PATH` liegt, und dieses Skript ausführbar mache, kann ich das `sync.sh` Skript dazu bringen, mein schädliches `diff`-Skript als Benutzer `sabulaji` auszuführen.
Empfehlung (Pentester): Analysieren Sie Skripte, die mit `sudo` ausgeführt werden dürfen, auf Schwachstellen wie unsichere Nutzung von Benutzereingaben, PATH-Hijacking (wenn relative Pfade verwendet werden oder der PATH nicht sicher gesetzt ist), oder Race Conditions. Nutzen Sie PATH-Hijacking, um ein eigenes schädliches Binary/Skript auszuführen, wenn Sie das anfällige Skript mit erhöhten Rechten ausführen dürfen.
Empfehlung (Admin): Setzen Sie den `PATH` in Skripten, die mit erhöhten Rechten ausgeführt werden, immer explizit auf sichere Systempfade (z.B. `PATH=/usr/sbin:/sbin:/usr/bin:/bin`). Verwenden Sie vollständige Pfade zu Binaries (`/usr/bin/diff` anstelle von `diff`). Überprüfen Sie Skripte auf unsichere Nutzung von Benutzereingaben oder temporären Dateien. Stellen Sie sicher, dass Skripte, die mit `sudo` ausgeführt werden, nur für Root schreibbar sind.
-rwxr-xr-x 1 root root 385 May 16 01:39 /opt/sync.sh
Ich überprüfte die Berechtigungen des `/opt/sync.sh` Skripts selbst. Die Ausgabe zeigte, dass die Datei Root gehört und für Root les- und schreibbar ist, aber für andere (einschließlich `welcome`) nur les- und ausführbar (`-rwxr-xr-x`). Dies bestätigte, dass ich das Skript selbst als `welcome` nicht manipulieren konnte. Die Ausnutzung musste über die PATH-Hijacking-Schwachstelle im Skript erfolgen, wenn ich es mit `sudo` als `sabulaji` ausführe.
Bewertung: Die korrekten Berechtigungen für das Skript selbst bestätigten, dass die Schwachstelle nicht in den Dateirechten lag, sondern in der unsicheren Implementierung des Skripts (`diff`-Aufruf ohne sicheren PATH).
Empfehlung (Pentester): Überprüfen Sie Berechtigungen von Skripten, die mit `sudo` ausgeführt werden dürfen. Wenn Sie das Skript nicht schreiben können, suchen Sie nach anderen Schwachstellen im Skript selbst oder im Ausführungskontext.
Empfehlung (Admin): Stellen Sie sicher, dass Skripte, die mit erhöhten Rechten ausgeführt werden, nur für Root schreibbar sind.
Ich bereitete die Ausnutzung der PATH-Hijacking-Schwachstelle im `/opt/sync.sh` Skript vor. Ich wechselte in das `/tmp` Verzeichnis, das für `welcome` schreibbar war. Dort erstellte ich ein neues Skript namens `diff` (`echo "/bin/bash" > diff`), das einfach `/bin/bash` ausführt. Ich machte dieses Skript ausführbar (`chmod +x diff`). Dann erstellte ich eine leere Datei namens `test` (`touch /tmp/test`), die ich als Argument an `/opt/sync.sh` übergeben würde.
Bewertung: Die Vorbereitung des schädlichen `diff`-Skripts im `/tmp` Verzeichnis war entscheidend. Da `/tmp` oft im standardmäßigen Benutzer-PATH enthalten ist (oder durch Manipulation des PATHs priorisiert werden kann) und schreibbar ist, kann ich hier ein Skript platzieren, das vor dem echten `/usr/bin/diff` gefunden wird. Wenn `/opt/sync.sh` dann `diff` ohne vollständigen Pfad aufruft und ich den PATH so manipulieren kann, dass `/tmp` zuerst durchsucht wird, wird mein schädliches Skript als Benutzer `sabulaji` ausgeführt.
Empfehlung (Pentester): Wenn Sie PATH-Hijacking ausnutzen, erstellen Sie Ihr schädliches Binary/Skript an einem schreibbaren Ort (wie `/tmp`). Benennen Sie es genauso wie das anfällige Kommando im Skript. Stellen Sie sicher, dass Ihr schädliches Skript ausführbar ist und das gewünschte Kommando ausführt (hier `/bin/bash`).
Empfehlung (Admin): Konfigurieren Sie temporäre Verzeichnisse mit `noexec`. Überwachen Sie die Erstellung von ausführbaren Dateien in temporären Verzeichnissen.
sudo: sorry, you are not allowed to set the following environment variables: PATH
Ich versuchte, das `/opt/sync.sh` Skript mit manipuliertem PATH auszuführen. Der Befehl `sudo -u sabulaji PATH=/tmp:$PATH /opt/sync.sh /tmp/test` sollte das Skript als Benutzer `sabulaji` ausführen (`-u sabulaji`), den PATH so setzen, dass `/tmp` zuerst durchsucht wird (`PATH=/tmp:$PATH`), und `/tmp/test` als Argument übergeben. Der Versuch schlug jedoch fehl. Die Fehlermeldung `sudo: sorry, you are not allowed to set the following environment variables: PATH` zeigte, dass die `sudo` Konfiguration es mir nicht erlaubte, die Umgebungsvariable `PATH` zu setzen.
Bewertung: Das Scheitern dieses Versuchs zeigte, dass die `sudo` Konfiguration standardmäßig verhindert, dass Benutzer bestimmte Umgebungsvariablen setzen, wenn sie `sudo` verwenden. Dies ist eine gängige Härtungsmaßnahme gegen PATH-Hijacking. Ich musste eine andere Methode finden, um sicherzustellen, dass mein schädliches `diff`-Skript im PATH gefunden wird, ohne den PATH selbst über `sudo` zu setzen.
Empfehlung (Pentester): Beachten Sie `sudo` Einschränkungen beim Setzen von Umgebungsvariablen. Suchen Sie nach alternativen Methoden, um den PATH zu beeinflussen (z.B. durch das Platzieren des Skripts in einem Verzeichnis, das standardmäßig im PATH des Zielbenutzers liegt und vor den Systempfaden durchsucht wird).
Empfehlung (Admin): Beschränken Sie die Umgebungsvariablen, die Benutzer mit `sudo` setzen dürfen (`env_keep`, `env_reset`). Stellen Sie sicher, dass `PATH` nicht manipuliert werden kann.
Ich war Mitglied der Gruppe `mlocate`, wie durch meinen `id`-Befehl als `welcome` bestätigt wurde. Die Gruppe `mlocate` hat typischerweise Leseberechtigungen für die mlocate-Datenbank (`/var/lib/mlocate/mlocate.db`). Diese Datenbank enthält einen Index aller Dateien auf dem System und kann manchmal sensible Dateinamen oder Pfade preisgeben, die sonst schwer zu finden wären. Ich suchte nach der mlocate-Datenbankdatei und las ihren Inhalt mit `strings` aus, um lesbaren Text zu extrahieren.
Bewertung: Die `mlocate.db` Datenbank ist eine wertvolle Informationsquelle, die Dateipfade enthalten kann, die mir auf andere Weise verborgen bleiben würden. Das Auslesen dieser Datenbank war ein logischer Schritt, um nach weiteren Hinweisen oder sensiblen Dateien zu suchen, die mir helfen könnten, mich zu `sabulaji` oder `root` zu eskalieren.
Empfehlung (Pentester): Wenn Sie Mitglied der Gruppe `mlocate` sind, lesen Sie die mlocate-Datenbank aus (`/var/lib/mlocate/mlocate.db`) und durchsuchen Sie sie nach interessanten Dateinamen oder Pfaden.
Empfehlung (Admin): Stellen Sie sicher, dass die mlocate-Datenbank (`/var/lib/mlocate/mlocate.db`) nur für die notwendigen Benutzer lesbar ist.
/usr/include/mlocate ... .. /var/lib/mlocate/mlocate.db ... ..
/home/sabulaji /home/sabulaji/personal
Ich las den Inhalt der mlocate-Datenbank aus und filterte die Ausgabe mit `grep '/home/sabulaji'`, um alle Zeilen zu finden, die Pfade unter dem Home-Verzeichnis von `sabulaji` enthielten. Die Ausgabe bestätigte die Existenz des Verzeichnisses `/home/sabulaji` und des Unterverzeichnisses `/home/sabulaji/personal`.
Bewertung: Dies bestätigte Pfade, die mir helfen könnten, Dateien zu finden, auf die `sabulaji` zugreift oder die ihm gehören. Das `/home/sabulaji/personal` Verzeichnis schien besonders interessant.
Empfehlung (Pentester): Nutzen Sie `mlocate.db`, um Pfade zu interessanten Verzeichnissen oder Dateien zu finden.
Empfehlung (Admin): Stellen Sie sicher, dass die mlocate-Datenbank nicht sensitive Dateinamen oder Pfade preisgibt, die auf versteckte Bereiche hindeuten könnten.
creds.txt pi_getscript.txt scroll.txt
Ich durchsuchte die mlocate-Datenbank weiter nach Dateinamen, die auf Zugangsdaten oder interessante Skripte hindeuten könnten, indem ich die Ausgabe von `strings` durch `grep -E 'cr.*.txt'` filterte. Dieser reguläre Ausdruck suchte nach Dateinamen, die mit "cr" beginnen und mit ".txt" enden, was auf Dateien wie "creds.txt" (Credentials) hindeuten könnte. Die Ausgabe zeigte die Dateinamen `creds.txt`, `pi_getscript.txt` und `scroll.txt`.
Bewertung: Das Auffinden von `creds.txt` in der mlocate-Datenbank ist ein sehr starker Hinweis auf eine Datei, die Zugangsdaten enthalten könnte. Die anderen Dateinamen klingen ebenfalls potenziell interessant. Ich musste nun versuchen, den genauen Pfad zu `creds.txt` zu finden und diese Datei auszulesen, um die Zugangsdaten zu erhalten.
Empfehlung (Pentester): Nutzen Sie reguläre Ausdrücke mit `grep` beim Durchsuchen von Datenbanken oder großen Textdateien nach interessanten Mustern oder Dateinamen (z.B. `pass`, `cred`, `key`, `secret`).
Empfehlung (Admin): Stellen Sie sicher, dass sensible Dateinamen nicht in der mlocate-Datenbank oder anderen Systemindizes erscheinen, die für unprivilegierte Benutzer lesbar sind.
Ich vermutete, dass die Datei `creds.txt` in `/home/sabulaji/personal/` lag, basierend auf der vorherigen `mlocate.db` Ausgabe. Ich nutzte die `sudo -u sabulaji /opt/sync.sh` Schwachstelle erneut, um den Inhalt von `/home/sabulaji/personal/creds.txt` auszulesen. Das Skript `/opt/sync.sh` verwendet den `diff`-Befehl auf die übergebene Datei und `/home/sabulaji/personal/notes.txt` und gibt den Unterschied aus. Ich übergab `/home/sabulaji/personal/creds.txt` als Argument an `/opt/sync.sh` und führte es als `sabulaji` aus. Das Skript verglich `creds.txt` mit `notes.txt` und gab den Unterschied aus.
Bewertung: Die Ausgabe des `diff`-Befehls zeigte den Inhalt von `creds.txt`. Am Ende der Ausgabe stand `Sensitive Credentials:Z2FzcGFyaW4=`. Der String `Z2FzcGFyaW4=` sah wie ein Base64-kodierter String aus. Dies war der entscheidende Hinweis auf Zugangsdaten.
Empfehlung (Pentester): Nutzen Sie jede Schwachstelle maximal aus, um Informationen zu extrahieren. Wenn Sie Code ausführen können, lesen Sie Dateien aus. Analysieren Sie die Ausgabe von Skripten genau, auch wenn sie Fehler oder Unterschiede anzeigen.
Empfehlung (Admin): Stellen Sie sicher, dass Skripte keine sensiblen Informationen preisgeben, selbst wenn sie mit begrenzten Rechten ausgeführt werden.
Difference: 1,27c1 < root:x:0:0:root:/root:/bin/bash < daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin < bin:x:2:2:bin:/bin:/usr/sbin/nologin < sys:x:3:3:sys:/dev:/usr/sbin/nologin < sync:x:4:65534:sync:/bin:/bin/sync < games:x:5:60:games:/usr/games:/usr/sbin/nologin < man:x:6:12:man:/var/cache/man:/usr/sbin/nologin < lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin < mail:x:8:8:mail:/var/mail:/usr/sbin/nologin < news:x:9:9:news:/var/spool/news:/usr/sbin/nologin < uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin < proxy:x:13:13:proxy:/bin:/usr/sbin/nologin < www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin < backup:x:34:34:backup:/var/backups:/usr/sbin/nologin < list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin < irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin < gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin < nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin < _apt:x:100:65534::/nonexistent:/usr/sbin/nologin < systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin < systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin < systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin < systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin < messagebus:x:104:110::/nonexistent:/usr/sbin/nologin < sshd:x:105:65534::/run/sshd:/usr/sbin/nologin < welcome:x:1000:1000:,,,:/home/welcome:/bin/bash < sabulaji:x:1001:1001::/home/sabulaji:/bin/bash --- > Sensitive Credentials:Z2FzcGFyaW4= [+] Updated.
gasparin
Ich dekodierte den Base64-String `Z2FzcGFyaW4=` mit dem Befehl `echo "Z2FzcGFyaW4=" | base64 -d`. Das Ergebnis war die Zeichenkette `gasparin`.
Bewertung: Das dekodierte Wort `gasparin` war offensichtlich das Passwort für den Benutzer `sabulaji`. Dies ist ein kritischer Fund und ermöglicht mir nun, mich als Benutzer `sabulaji` anzumelden. Dies ist der nächste Schritt in der Privilegieneskalation.
Empfehlung (Pentester): Dekodieren Sie alle verdächtigen Base64-Strings. Sie enthalten oft sensible Informationen wie Passwörter.
Empfehlung (Admin): Speichern Sie niemals Zugangsdaten in Klartext oder einfach kodierter Form auf Systemen.
Password: gasparin sabulaji@Sabulaji:/tmp$
Mit dem gefundenen Passwort versuchte ich, die Benutzeridentität auf der `welcome` Shell zu `sabulaji` zu wechseln. Ich verwendete den Befehl `su sabulaji` und gab das Passwort `gasparin` ein. Nach erfolgreicher Authentifizierung erhielt ich eine Shell als Benutzer `sabulaji`. Ich machte einen kurzen Tippfehler und versuchte es erneut, was dann funktionierte.
Bewertung: Erfolgreich! Ich habe die Privilegieneskalation von `welcome` zu `sabulaji` erreicht, indem ich das gefundene Passwort nutzte. Ich habe nun Zugriff als ein weiterer regulärer Benutzer, der wahrscheinlich höhere Berechtigungen als `welcome` hat und das nächste Ziel vor `root` darstellt.
Empfehlung (Pentester): Nutzen Sie gefundene Passwörter sofort, um sich an der Shell anzumelden (`su`) oder per SSH.
Empfehlung (Admin): Erzwingen Sie starke Passwörter. Überwachen Sie Login-Versuche.
Matching Defaults entries for sabulaji on Sabulaji: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User sabulaji may run the following commands on Sabulaji: (ALL) NOPASSWD: /usr/bin/rsync
Als Benutzer `sabulaji` prüfte ich sofort meine `sudo`-Berechtigungen mit `sudo -l`. Die Ausgabe zeigte eine sehr interessante Regel: `(ALL) NOPASSWD: /usr/bin/rsync`. Dies bedeutete, dass der Benutzer `sabulaji` das Programm `/usr/bin/rsync` als *jeder* Benutzer (`ALL`), einschließlich `root`, ausführen darf, ohne ein Passwort einzugeben (`NOPASSWD`).
Bewertung: Das ist der direkte Weg zur Root-Privilegieneskalation! Eine `NOPASSWD` Regel für `rsync` ist eine hochgradig ausnutzbare Schwachstelle. Ich darf `rsync` mit Root-Berechtigungen ausführen, ohne ein Passwort zu benötigen. Rsync hat Funktionen, die das Ausführen von Shell-Befehlen ermöglichen, wenn es als Server oder im Kontext der Remote Shell ausgeführt wird.
Empfehlung (Pentester): Prüfen Sie immer die `sudo`-Berechtigungen. `NOPASSWD` Regeln für Programme wie `rsync` sind oft direkt über GTFOBins ausnutzbar. Nutzen Sie diese, um eine Root-Shell zu erhalten.
Empfehlung (Admin): Weisen Sie `NOPASSWD` Berechtigungen nur mit äußerster Vorsicht zu. Überprüfen Sie Ihre `sudoers`-Datei auf unsichere Einträge, insbesondere für Dateisynchronisierungs- oder Übertragungstools.
[Link: https://gtfobins.github.io/gtfobins/rsync/#sudo | Ziel: https://gtfobins.github.io/gtfobins/rsync/#sudo] Sudo If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access sudo rsync -e 'sh -c "sh 0<&2 1>&2"' 127.0.0.1:/dev/null
Ich konsultierte GTFOBins ([Link: https://gtfobins.github.io/gtfobins/rsync/#sudo | Ziel: https://gtfobins.github.io/gtfobins/rsync/#sudo]), um eine Methode zur Ausnutzung von `sudo rsync` zu finden. Die Website bietet eine spezifische Anleitung dafür. Die empfohlene Methode nutzt die `-e` Option von rsync, die ein Remote Shell Programm angibt. Man kann hier `sh -c "sh 0<&2 1>&2"` einfügen, um eine interaktive Shell zu erhalten. Der Befehl lautete `sudo rsync -e 'sh -c "sh 0<&2 1>&2"' 127.0.0.1:/dev/null`.
Bewertung: GTFOBins lieferte den exakten Befehl, um die `sudo rsync` Schwachstelle zur Erlangung einer Root-Shell auszunutzen. Diese Methode ist bekannt und zuverlässig.
Empfehlung (Pentester): Nutzen Sie GTFOBins, um die Ausnutzung von SUID-Binaries oder `sudo`-anfälligen Programmen zu finden.
Empfehlung (Admin): Überprüfen Sie die auf GTFOBins gelisteten Binaries auf Ihren Systemen.
Kurzbeschreibung: Dieser Proof of Concept demonstriert die erfolgreiche Erlangung vollständiger Root-Privilegien auf dem Zielsystem durch die Ausnutzung einer Fehlkonfiguration in der `sudoers`-Datei. Der Benutzer `sabulaji` war berechtigt, das Programm `/usr/bin/rsync` ohne Passwort als Root auszuführen. Durch die Nutzung der `-e` Option von rsync konnte eine interaktive Root-Shell erlangt werden.
Voraussetzungen:
Schritt-für-Schritt-Anleitung & Beweismittel:
1. Überprüfung der `sudo`-Berechtigungen des Benutzers `sabulaji`:
... User sabulaji may run the following commands on Sabulaji: (ALL) NOPASSWD: /usr/bin/rsync
Als Benutzer `sabulaji` wurde festgestellt, dass `/usr/bin/rsync` ohne Passwort als Root ausgeführt werden darf.
2. Ausführung von `rsync` mit manipuliertem Remote Shell Parameter zur Erlangung einer Root-Shell:
# id uid=0(root) gid=0(root) groups=0(root) # ls diff systemd-private-fa8e89c99b04486a86a15620aacc1c17-apache2.service-dkEkqi systemd-private-fa8e89c99b04486a86a15620aacc1c17-systemd-logind.service-1GUNAf systemd-private-fa8e89c99b04486a86a15620aacc1c17-systemd-timesyncd.service-3BtRdj test # cd ~ # ls root.txt # cat root.txt flag{root-89e62d8807f7986edb259eb2237d011c} #
Ich führte den von GTFOBins bereitgestellten Befehl `sudo rsync -e 'sh -c "sh 0<&2 1>&2"' 127.0.0.1:/dev/null` aus. Dieser Befehl nutzte die `sudo` Berechtigung, um rsync als Root auszuführen, und injizierte über die `-e` Option einen Bash-Befehl, der eine interaktive Shell initiierte. Ich erhielt sofort eine Root-Shell, erkennbar an der Eingabeaufforderung `#`. Innerhalb dieser Shell verifizierte ich meine Identität mit `id` (was `uid=0(root)` zeigte) und navigierte in das Home-Verzeichnis von Root (`cd ~`), um die Root Flag (`root.txt`) zu finden und auszulesen. Fantastisch der root zugriff war erfolgreich nun haben wir unser Ziel erreicht.
Erwartetes Ergebnis: Erlangung einer interaktiven Shell mit Root-Berechtigungen auf dem Zielsystem.
Tatsächliches Ergebnis: Eine interaktive Root-Shell wurde durch die Ausnutzung der `sudo rsync` Schwachstelle erlangt, was die vollständige Kompromittierung des Systems ermöglichte und den Zugriff auf die Root Flag erlaubte.
Risikobewertung:
Auswirkung: Kritisch. Ein unprivilegierter Benutzer (`sabulaji`) konnte durch die Ausnutzung einer unsicheren `sudo`-Berechtigung vollständige administrative Kontrolle über das System erlangen.
Wahrscheinlichkeit: Hoch. Die Schwachstelle war direkt über einen vorhandenen `sudo`-Eintrag ausnutzbar und erforderte nur die Anwendung einer bekannten Ausnutzungstechnik für `rsync`.
Gesamtrisiko: Kritisch.
Empfehlungen:
Empfehlung (Admin):